大数据集群监控体系

背景：企业级的数据集群往往有PB 级的数据、成百上千的各类型运算任务在一套集群上运行。所以它的维护是充满挑战的：庞大的数据量、复杂的运算逻辑、相互关联的大数据组件、数以万计的运行任务都是要克服的难点。SRE 需要做好各式监控，预防风险、提前发现风险、然后分析问题、进而针对性的处理问题。 

凡是成体量的分布式系统，一旦出现性能问题，往往很难在短时间内作出有效处理。所以监控要前置，有趋势预测、有风险评估才行。

01

大数据监控体系

1.1、 Not Only Monitor

首先，监控在我们的大数据运维体系中定位如下，处于承上启下，贯穿全局的角色。 

这里为什么说Not Only Monitor 呢？是因为数据监控所包含的范围其实很大，不只是传统的运维底层监控。还包含了比如数据质量监控、任务状态监控、组件性能监控、趋势预测监控、同比环比分析等。 

1.2、大数据监控体系整体架构

整个大数据集群的监控体系分为如下七个维度：

其实上面每个维度，都包含了很多的监控项与监控指标，而不同的维度，监控方式也不尽相同。   

• 一些监控是不断读取它的状态，比如常见的CPU、内存，然后设定阈值触发告警动作；

• 一些监控是需要有时序性的聚合统计，比如HDFS存储增量，当增量斜率比平时高的时候触发告警动作；

• 一些监控是需要和其他监控做联动，同时满足才会触发告警动作。

......

针对这些不同的监控指标，单纯的一个监控组件或者数据采集方式是不能满足的。光靠开源的监控手段也无法全部覆盖，所以我们做了各式组件+自研的监控脚本与程序去实现整体的监控框架。 

整个7 个维度，按照不同的框架与组件，主要分为基础监控与升级监控两部分。我们分别来聊，本章主要讲基础监控。

02

基础监控

2.1、基础监控框架

基础监控包含：底层基础监控、服务状态监控、组件性能监控、Runtime监控 这四部分。基础监控架构比较简单：

主要分为 3 大块，我们分别简单介绍一下。

2.2、第一块：底层基础监控  

这部分比较简单，主要对所有的网络、服务器 进行实时监控数据收集。因为我们同时负责了不同的事业部与部门的运维工作，所以进行了分组、分模版、分告警渠道的形式，实现对不同部门的告警。但同时为了避免重复维护，我们尽量复用告警模版。

因为很多业务类型的告警都是类似的，所有的项目模块都需要对Java进程，Nginx进程进行监控，那我们就划分两个分组，同时和一个Java 进程告警模版相关联。而不是创建两个：

如上，业务模块对应的主机群组，不同的主机群组可以复用相同的告警模版。  比如不管是培优还是网校、不管是业务还是集群、底层服务器的 CPU、内存等基础监控都得有。所以就可以复用同一个告警模版。  

PS：有时候会遇到相同告警模版，相同监控项，但是监控阈值不同。  比如虽然业务服务器 和 大数据集群服务器 都需要监控 CPU ，但是业务服务器只要超过65% ，我们就认为是异常，但是大数据服务器在高峰期可能长时间处于 90% 左右的CPU利用率，那么它的阈值要更高，并且持续时长也要更高些。

对于这块我们只是力求把它用好，尽可能通过划分组、复用模版 的方式让它更清晰、整洁、高效。 

2.3、第二块：集群性能监控

对大数据组件的性能监控，主要分为四步：

• 自建Flask exporter，从集群的API中取出各式组件需要监控的 Metrics ；

• 通过Alertmanager对需要的metrics进行告警；

• 自建知音楼+电话告警API供Alertmanager调用；

• 将Prometheus data source接入Grafana做报表展示。

具体的实现与代码略过，最终可以将结果汇聚成报表的形式，方便查看：

2.4、第三块：Runtime Monitor

所谓Runtime Monitor其实给它的定位是轻量级的模拟客户端交互监控程序。即用Python编写客户端，循环的每隔一段时间去和HDFS 、Hive 等组件进行基本交互。

与每个核心组件进行链接、新增、修改、更新、删除等基本操作，每次一个小闭环。

这样做的意义在于兜底。因为我们虽然加了很多基础监控，但是你不能100%确定采集到的Metrics 是准确、无延迟 并且高可用的。我们线上曾经出现过Zabbix自己挂了，从而所有基础告警本身失效，从而漏报核心业务模块故障的Case。

Runtime Monitor作为一个客观独立存在的小闭环，它确保你的服务最基础的核心能力在正常运行。一旦Runtime Monitor 出现异常，那往往是线上服务就出现核心异常了。

Runtime最好做成一个体系化的架构，不要变成东一个小脚本、西一个小定时。  

具体这块的代码架构这里就不再详细赘述了。  

截止目前，基础监控三大块就讲完了。其实每一块都有很多细节，这里简单介绍了下监控的框架和维度，后续可能会单独针对每一块做一些专项深入的交流和分享。 

03

监控升级

3.1 升级监控架构简述

基础监控三大块是生命线，它能保证对基础环境运行状态的监测。 

但还不够，集群指标监控、趋势预测监控、任务运行监控也是我们必须要关注的东西，这些是属于升级监控。 

升级监控体系略微复杂一些，需要有一些数据采集、聚合、分析等能力。而且一些集群数据需要有运维数仓，进行 T+1的任务计算，以及多指标关联分析等。 

这里我们用到了ES、Kakfa、Logstash、Flink、Hive等各种大数据分析组件，也基于Flask框架进行了很多数据加工，同时运用了一些大数据思想。给一些核心组件比如NameNode RPC做了运维画像。也对集群的各式任务进行了分析与治理。

升级监控简明架构：

3.2、集群基础信息升级监控

如上，升级监控分为了很多模块，详细的我们留在下篇再进行分享，这里我们先简单附上升级监控的一些结果。 

CPU、内存的周环比、集群存储剩余可用时长预测、每日各维度数据增量：

数据表分布、活跃用户分布、活跃任务分布等：

任务相关分布分析：

 3.3、任务相关升级监控

另外为了让监控告警更加透明高效，我们在关于数据运维平台上开放了关于配置自动化运维告警的配置，可以让用户按需配置自己关注的监控，并选择合适的告警方式给到自己：

如上，用户可以根据自己的情况定义告警模版来设置自己关心的告警以合适的方式推送给自己。

此外，集群每天运行的任务很多，哪些任务是否合理，对资源是否有浪费，是否有优化空间，该如何优化，我们也进行了关于任务的监控分析：

还有很多，包括实现方式，这里就不再展开了，下篇会专门再专门讲一下升级监控的架构与具体实现原理与细节。 

04

浅谈告警收敛与告警分级

其实光是告警收敛和告警分级 每个都可以单拉出来，有很多内容。很重要，做深了也很有挑战。我自己这方面的经验也不深，只是做了一些简单的探索和实践。这里将仅有的实践和大家探讨一下。 

我觉得一条有效的告警，它的生命旅程是非常坎坷的，理想情况下它应该经历这样的旅程：

如上，它得经过一层层的筛选、过滤、汇总、定向 才发给真正需要知道它的人，从而实现自己的生命价值。 

这里我将告警收敛 和 告警分级都标注出来了，下面谈谈。其他的这里就不再展开了，其实做好监控是非常复杂的一件事情。如何与组织树和值班信息联动，如何进行告警的分类分级统计，如何进行告警流量清洗，这些都是很值得深入研究的。 

4.1、监控告警收敛

我经常给伙伴们强调的一句话：理想情况下，要么不报，只要报出来那就是一定是需要我们立刻关注处理的。  

• 目前，我们负责多个事业部、对接10+个部门、几套大数据集群、各种组件，所以分了将近十多个告警群；

• 每天的告警消息数大概平均保持在60 - 100之间； 

• 每天有效告警只占所有告警的不到10%；

• 而由于大数据夜间是高峰期，所以一些核心报警是加了电话通知的，如果你不想半夜被叫醒却发现是误报，那就必须要进行告警收敛。  

其实告警收敛的核心目的是提升告警有效性，确保问题能在第一时间得到妥善处理。目前我们的告警收敛做的比较糙，主要分为三部分：

• 底层基础监控就单纯的根据进一步细分主机群组和监控模版，比如Datanode独立一个基础监控，将阈值调高，不至于频繁告警；

• 性能监控就 基于 Prometheus 等组件的告警分组特性进行了一些常态化的告警收敛；

• 自建升级监控目前是根据一些简单计算公式进行收敛策略，我一直觉得这块其实大有可为，后面我们逐步要做DataOps和AiOPS的时候可以基于Flink等通过大量的实时算法策略做告警收敛。

经过三种方式我们目前的告警收敛效果可以到 60% 左右，这块仍然有很大的优化空间。

这里也附上我对告警收敛的一点思考。 

首先，它是一个细活，当到一定规模和体量的时候，必然要深入算法，去建模，对监控流量进行分析。从而达到类似AIOPS的效果，进行故障自愈和智能巡检等效果。而想要做到这一步还是要有比较专业的团队去聚焦，做监控平台。而监控平台一个很大的挑战将会是，平台如何有通用的产品能力，去适配不同业务场景的监控告警功能。   

4.2、监控告警分级 

监控告警分级也是至关重要的，当监控的东西越来越多的时候，就得给这些家伙进行分级管理了。有些监控告警是P0级，它很重要，一旦出现就需要引起我们的高度重视，快速响应，一般我们要求是触发电话通知，并通知到对应的值班人、负责人等。而有些监控项它更多的是偏提示或者预警，那么就要做好分类管理。  

针对线上的一些告警，进行了如下分类分级（内容太多，这里只截取了一小部分）：

如上，根据不同的监控项、监控类型，分别针对线上的监控做了告警分级处理。我们规定，所有的P0 级告警，全部走电话+知音楼通知，所有的 P1 级告警都走对应的知音楼核心群通知。P2及以上告警收敛覆盖率要达到 80%。 

好的告警分级能减轻运维人员自己的负担，也能使告警更有效清晰。

但如何打造一套完整的告警分级体系，还需要贴合业务场景并且有监控数据分析，综合去评定。一旦有了这样的体系，那么后面要做的就是不断补充完善这个体系。出故障的时候也能按图索骥，根据监控告警分级策略不断打磨完善。  

关于基础监控体系，今天就先谈到到这里，篇幅有限，主要是对一些框架和实现思路的交流。

未完待续 ～

扫描下方二维码添加「好未来技术」微信官方账号

进入好未来技术官方交流群与作者实时互动~

(若扫码无效，可通过微信号TAL-111111直接添加)

- 也许你还想看 -

我知道你“在看”哟～